@suhlrich I added support for running torque-driven simulations. It makes the code even messier, but it is nice for testing since it is very fast. I added an example: https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/example_kinetics.py#L151

When setting torque-driven to True (https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/UtilsDynamicSimulations/OpenSimAD/mainOpenSimAD.py#L309), torque actuators are used instead of muscles. There is some simple dynamics (first order approximation of a time-delay of 35ms: https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/UtilsDynamicSimulations/OpenSimAD/functionCasADiOpenSimAD.py#L109) and you can specify the optimal forces through the settings (example https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/UtilsDynamicSimulations/OpenSimAD/settingsOpenSimAD.py#L199). By default the optimal forces are defined here: https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/UtilsDynamicSimulations/OpenSimAD/muscleDataOpenSimAD.py.

Tests I have done:

• Ran muscle-driven simulations and got same solution as before
• Ran torque-driven simulations and got something looking okay. FYI I ran the running one and got almost the same GRFs as with the muscle driven simulation (torques were quite different though)
• All the sanity tests pass

Question:

• I skipped computing MKCF: https://github.com/stanfordnmbl/opencap-processing/blob/issue_65/UtilsDynamicSimulations/OpenSimAD/mainOpenSimAD.py#L2320, does that make any sense to try? If so I would suggest we merge and add as an issue for later.